Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000040_owner-urn-ietf _Tue Nov 5 10:54:41 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19183 for urn-ietf-out; Tue, 5 Nov 1996 10:54:41 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19178 for <[e-mail]>; Tue, 5 Nov 1996 10:54:39 -0500
Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA02105  (mail destined for [e-mail]); Tue, 5 Nov 96 10:54:25 -0500
Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:54:06 +0000
Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:53:46 +0000
Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 15:52:59 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 05 Nov 1996 15:55:06 +0000
To: Fisher Mark <[e-mail]>
From: Bob Briscoe <[e-mail]>
Subject: RE: [URN] Resolution Services (N2L etc)
Cc: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Bob Briscoe <[e-mail]>
Errors-To: [e-mail]

At 07:41 05/11/96 EST, Fisher Mark wrote:
>
>>1.2 It strikes me that specifying available service requests (N2L, N2R etc)
>>should not be the job of DNS or any URN resolution mechanism. You are
>>adding
>>metadata about the address that the name resolves to (i.e. allowed
>>methods).
>>NAPTR should simply get you to the place you asked for by mapping names to
>>addresses.
>[...]
>>OK, it may be *easier* to hack it this way, but that's not the point. You
>>are embedding a duplication of meta-information in DNS which will always be
>>prone to being out of date, unreliable, etc. Especially if the world moves
>>to be much more dynamic in this area in the decades you envisage this
>>lasting. More importantly, this information potentially has a different TTL
>>than the address itself, so it will break your caching.
>
>But this is meta-information that is not easy to change.  It is not like,
>"oh, from midnight to 6am I'll support HTTP, then from 6am to 8am I'll
>support HTTP and our experimental Z39.50-2000, then from 8am-6pm I'll only
>support whois++", etc.  Rapidly changing what final resolution services are
>supported is not a particularly easy task, or a desirable task even when it
>is made easy.

I'm not throwing out the resolution service, as you appear to think I am
saying. I'm throwing out the service requests supported by that service
(N2L, N2Ls, N2R, N2Rs, N2C etc.). This is one level of indirection too far.

It's irrelevant whether they are likely to change *often*. What is important
is that they will change at potentially *different* times to the resolution
service. This is what breaks the meaning of the TTL. Once you have the
resolution service you can find the service requests it supports, so this is
unnecessary complexity.

>
>Could one (or more) of the DNS wizards on the list speak as to what the
>average TTL tends to be?  From what Bob is saying, it sounds like he expects
>the TTL of the NAPTR record to be a longer time than the expected time
>between final resolution service changes.
>======================================================================
>Mark Leighton Fisher                   Thomson Consumer Electronics
>[e-mail]                   Indianapolis, IN
>
>
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm